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I ABSTRACT 

This paper introduces an automatic debugging framework that relies on model-based reasoning techniques 
• to locate faults in programs. In particular, model-based diagnosis, together with an abstract interpretation 

based conflict detection mechanism is used to derive diagnoses, which correspond to possible faults in pro- 
grams. Design information and partial specifications are applied to guide a model revision process, which 
allows for automatic detection and correction of structural faults. 
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m ■ 1 Introduction 

O 

Detecting a faulty behavior within a program, locating the cause of the fault, and fixing the fault 
by means of changing the program, continues to be a crucial and challenging task in software de- 
velopment. Many papers have bee n publishe d so far in the domain of detecting faults in software, 
e.g., testing or formal verification lCDH + 00l , and locating them, e.g., program slicing IWei84l and 
automatic program debugging I Llo87l . More recently model-based diagnosis |Rei87| has been used 
for locating faults in software ICFD93UMSWW02al . 

This paper extends previous research in several directions: Firstly, a parameterized debugging 
framework is introduced, which integrates dynamic and static properties, as well as design infor- 
mation of programs. The framework is based on results derived in the field of abstract interpreta- 
tion ICC77I . and can therefore be parameterized with different lattices and context selection strate- 
gies. 

Secondly, the one-to-one correspondence between model components and program statements 
is replaced by a hierarchy of components, which provides means for more efficient reasoning proce- 
dures, as well as more flexibility when focusing on interesting parts of a program. 

This work is organized as follows. In Section|21 we give an introduction to model-based debug- 
ging. Section [3] describes mapping from source code to model components and the (approximate) 
computation of program effects in the style of [CC77| and |Bou93[. The next section discusses the 
modeling of programs and the reasoning framework. In Section |5J we provide an example which 
puts together the different models and demonstrates the debugging capabilities of our approach. 
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Section|6]provides details about our implementation. Finally, we discuss related work and conclude 
the paper. 

2 Model-based Debugging 

To locate faults using model-based reasoning techniques, the source code of the program P to be ana- 
lyzed must be available. Also, a set of test cases TC is required, which (partially) specify the expected 
behavior of P. Test cases can be as simple as a set of input-output vectors or even just a list of correct 
and incorrect output variables. The connection to the model-based diagnostic framework is realized 
through a set COM PS and a set M. of models. COM PS contains the set of components of which 
fault candidates are composed, whereas each m £ A4 describes the program behavior (possibly at an 
abstract level) and is used to detect discrepancies between the expected and the obtained behavior of 
the program. A fault candidate in is a part of P's source code that, when assumed to show arbitrary 
effects, does not conflict with any test case in TC any more. A fault candidate conflicts with a test 
case t if the modified program corresponding to the fault candidate derives values different from 
the ones specifies in t. A model rn G M. of P is a (partial) description of the P's behavior, derived 
automatically from the source code of P. 

For example, using a model that describes dependencies between components, where each com- 
ponent corresponds to a statement, the (faulty) program 

1 int r = 3; 

2 float area = r*3. 141 f; 

3 float circ = 2.f*r*3.141f; 

can be described as follows. 

If statement 1 is correct, the value of r is correct. If statement 2 and r are correct, area is 
correct, too. circ is correct provided statement 3 and r are correct. 

Translated to first order logic, this can be represented as follows: 

(->a6(ci) — ► correct(r)) A 

(-10.0(02) A corrector) — > correct {area)) A 

(-10,6(03) A corrector) — > correct [circ)) . 

c\ to C3 represent the components corresponding to the statements in lines 1 to 3, respectively, and 
correct is a predicate that asserts that the variable passed as argument has the correct value (specific 
to the test case under consideration). Test cases are represented as conjunctions of correct literals. 
For example, correct (circ) A -^correct (area) expresses that after running the program, variable circ is 
correct, whereas area is incorrect, ab is used by the diagnostic engine to disable the model of certain 
components and check if the remaining model is still inconsistent with the test case. A more formal 
elaboration can be found below. 

We recall some of the basic definitions from model-based diagnosis |Rei87|, slightly adapted for 
our purposes: 

Definition 1 (Diagnosis Problem) A diagnosis problem is a triple (SD, COM PS, OBS) where SD is the 
system description, COM PS is the set of components in SD, and OBS is the set of observations. 

Here, SD s M is a model of P, and OBS € TC is the information specified by test cases. Note that 
OBS contains the expected result of test cases, not the actual result obtained from the faulty program. 
Also, OBS is not restricted to pure input and output specifications; intermediate results can also be 
checked using assertions (see Section l3~TV 
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Definition 2 (Diagnosis) A set A C COM PS is a diagnosis for a diagnosis problem (SD, COM PS, OBS) 
iffSD U OBS U {->ab(C)\C G COMPS \ A} z's consistent, where ab(C) denotes that component C is not 
working as specified in SD. 

Each component C G COMPS corresponds to a part of P and therefore, components in A indicate 
possible faults in the program. The ->a6(C) behavior of a component C is an abstraction |CC77| of the 
semantics of the code fragment represented by C, as given by the language specification. The ab(C) 
behavior denotes a possible fault and generally permits arbitrary effects. 

Diagnoses can be computed efficiently using the concept of conflicts, which are sets of compo- 
nents that cannot be all functioning correctly without contradicting at least one t E TC. 

Definition 3 (Conflict) A C COMPS is a conflict for (SD, COMPS, OBS) iffSDUOBSU{^ab(C)\C G 
A} is inconsistent. 

The basic principle of MBD is to use M. to derive conflicts given TC as observations. The con- 
flicts are then used by the diagnostic engine to compute diagnoses, which are mapped back to the 
program's source code to indicate possible faults. To minimize the number of fault candidates, we 
are only interested in subset-minimal diagnoses, which can be derived from subset-minimal con- 
flicts IRei87l . 

Revisiting the previous example, it is easy to see that {06(03)} cannot be a diagnosis, as the model 
derives the conflict {->a6(ci), -106(02)}. However, {ab(ci)} and {06(02)} are both diagnoses. {a6(ci) A 
06(03)} is also a diagnosis, but not subset-minimal, as it contains the diagnosis {a6(ci)}. 

As a possible extension not covered in this paper, the approach could be extended to output 
the most likely diagnoses, given prior probabilities for each component. These probabilities can be 
obtained by counting the number of correct and faulty test cases that the statements corresponding 



3 Modeling Program Behavior 

A key aspect of every MBD system is the construction of the set Ai of models and the mapping 
between the program and .Ms components. 

Previous work | MSWOO MSWW02a | derives the models from the source code without consider- 
ing runtime information, which often results in large and complex models. We construct the models 
dynamically, which, by exploiting runtime information, can lead to smaller and more concise models. 

Another limitation imposed by these earlier modeling approaches is the representation of every 
statement and (sub-)expression in P as a separate component in the model. Even though these mod- 
els allow for very detailed reasoning, this is rarely required in practice and leads to a large number 
of diagnoses and to increased computational requirements. 

To overcome these limitations, we employ an iterative, hierarchical diagnostic process, where the 
mapping from P to COMPS is refined incrementally (starting with a single component for each 
method), depending on the results of previous diagnostic analysis (see [FFJS00| for a similar ap- 



Previous models behave poorly when the number of loop iterations or recursion depth is not 
known in advance. The combination of static program analysis and dynamic execution proposed 
in the next sections provides an effective combination, which is well-suited for dealing with such 
constructs. 

3.1 Approximate Program Analysis 

Static program analysis, in particular Abstract Interpretation ICC77I , has successfully been applied 
to derive properties of programs, even in the absence of specific test cases. Also, the framework is 
customizable with different abstractions of the concrete semantics of a program. 




proach). 
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We recall the basic definitions of Abstract Interpretation, as given in ICC77IIBou93l : 

The mapping from the concrete semantics, represented as a lattice (V(S), 0, S, C, U, n) (S denotes 
the set of program states), to the abstract, finitely represented lattice, (V&(S), _L, T, C, U, n), is given 
by a Galois Connection (a, 7), where a maps sets of states to their best approximation, and 7 maps 
every abstract property to its meaning in V(S). 

The approximate semantics of a program P can then be expressed as fixpoint over a set X of equa- 
tions derived from P's source code. The equations are composed of abstract operations = 7o$oa, 
which model the effects of every operation $ in P. An approximation of the forward semantics is 
given by the solution of lfp XX ■ (E F\X(X)) (starting at _L), where E denotes the approximation of the 
entry states. In case the abstract lattice is of infinite height, narrowing and widening operators have 
to be applied to ensure termination of the computation. For a more in-depth discussion see 1ICC77I . 
Bourdoncle described similar approximations of backward semantics and added intermittent and 
invariant assertions for program analysis I Bou93l . 

To incorporate intermittent ("sometime") and invariant ("always") assertions into the analysis, 
a sequence of forward and backward reasoning steps can be defined to approximate the entry and 
exit states which guarantee the validity of the assertions |Bou93[. Intermittent assertions express 
conditions that must eventually hold in each program execution, but not necessarily each time the 
program point is reached. Invariant assertions on the other hand have to be true every time the 
corresponding program point is reached (if it is reached at all). For example, the assertion sometime 
true; at the end of a program asserts that the program must eventually terminate. Similarly, always 
i>=0 && i<=1 asserts that whenever that point of the program is reached, i must be between and 
10. Note that sometime and always assertions, contrary to what the names may imply, do not require 
the presence of multiple test cases. For example, consider a test case where a loop executes multiple 
iterations. In this case, the difference between sometime C and always C is evident: always requires 
condition C to be true in every iteration, whereas sometime only requires that for one iteration. 

3.2 Avoiding Imprecision 

The approximation of complex programs leads to possible imprecision, which is undesirable for au- 
tomatic debugging. In particular, (1) aliasing between variables has to be approximated, (2) it can 
be difficult to derive useful properties for arrays, and (3) partitioning of the domain of the abstrac- 
tion function severely impacts the outcome of the analysis. Further imprecision may be introduced 
by composition of the abstractions for each statement. To deal with (1) and (2), numerous different 
abstractions |HP00| and partial evaluation approaches |Col97) have been developed. However, they 
are generally not very well-suited for MBD, because the results are often too imprecise to derive 
a conflict. To overcome (3), IBou 92 1 introduced a model that is able to refine the domain based on 
the current partitioning. However, even in this framework, the choice of approximation operators 
remains crucial (and program dependent). 

To circumvent the aforementioned shortcomings, we employ the information from test cases to 
avoid approximation whenever possible, and rely on static analysis only as a fallback in case the 
program's behavior is only partially specified or exceeds user-defined bounds. A more detailed dis- 
cussion is provided in Section^] 

4 Model Construction 

In this section, we present a model that follows the execution semantics of the program. Based on 
the semantic approximation introduced in the previous section, a separate model for each test case 
is constructed by abstract interpretation of the program, using the entry state specified by the test 
case. Test case information (pre- and postconditions values, as well as intermediate assertions) is 
mapped to sometime and always assertions. This differs from traditional abstract interpretation tech- 
niques ICC77I as we generate the equations representing the system dynamically while the fixpoint 
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is computed, which is advantageous when combined with the MBD engine and partitioning strate- 
gies (see below). The model derives a contradiction iff there exists no feasible path between the entry 
state and the exit state of the program. 2 To determine the set of components the conflict is composed 
of, we follow the approach of [MT02|. The algorithm can be summarized as follows. After a conflict 
has been detected, the derivation tree is analyzed to find the subset-minimal set of constraint needed 
to derive the inconsistency. This is done by recursively subdividing the derivation tree and pruning 
sets that cannot contribute to the conflict. 

The dynamic approach, together with the test case information allows us to explore only these 
parts of the model which may actually be executed. Especially for object-oriented languages like 
Java, with many possibly exception-throwing statements, this approach results in significantly smaller 
models. For example, if a branch of a conditional can be eliminated, its statement need not be con- 
sidered and the data flow and a functions |Ana99| can be eliminated, too. 

4.1 Partitioning Strategies 

Crucial to the accuracy of the results is the selection of partitioning strategies for contexts of method 
calls. This corresponds to the selection of widening operators in IBou92l . We propose a heuristic 
strategy that introduces a new partition whenever the call is non-recursive or the calling statement 
is definitely executed for every possible execution of the model, and a common partition represent- 
ing the called method otherwise. The strategy can be further enhanced by bounding the depth of 
the call stack, possibly with different bounds for different categories of methods. The analysis and 
identification of useful heuristics constitutes an important part of future model refinement. To keep 
the analysis feasible, sparse representation of environments have to be used (see Section|6|for more 
details). 

Another key feature in the analysis of object-oriented programs is the abstraction of heap data 
structures and aliased variables. For abstracting heap data structures, any of the numerous heap 
abstraction approaches developed in the last decades can be applied. For simplicity, we propose the 
approach given by ICor9 81, where objects are abstracted into equivalence classes associated with the 
program point at which they were created. Note that simple approaches can lead to accurate results, 
as the partitioning strategies, together with the information from test cases, in many cases eliminate 
the need for approximation. 

4.2 Analyzing Loops 

For simplicity, we restrict the following discussion to while loops (other forms of iteration statements 
are treated similarly). 

In case the condition of the loop can be evaluated uniquely using the abstract environment, the 
corresponding branch is followed, unless a termination check is triggered. Otherwise, conventional 
static analysis of the loop is done. The environment before and after the loop, together with asser- 
tions from the test case, are used as entry and exit states for the analysis. Static analysis is used to 
strengthen the pre- and postconditions of the loop, which are subsequently used to derive conflicts. 

Note that in this approach, more precise results than with static analysis alone can be derived. 
This is because the values in the pre- and post environment are derived from test cases and, therefore, 
may be more precise than a purely static approximation. These values can in turn be used to derive 
approximation o perators fo r the static analysis, which are effective at proving a contradiction. This 
idea is similar to lCDH + 00l . where abstraction operators are guessed based on the structure of the 
program and the given proof obligation. 

Nontermination, 3 by necessity, has to be dealt with through heuristics, such as setting upper 
limits on loop iterations or recursion depth, or using the abstract interpretation model to determine 

2 Here, the assumption is made that the program is terminating; this issue is revisited below. 

3 Although we assume the given program is terminating on all test cases, nonterminating programs can arise due to abnor- 
mality assumptions set by the diagnostic engine. 
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if any of the successor statements of the loop (call) can be reached using the current environment as 
entry state for the loop (call). This is an avenue for future research. 

4.3 Correcting Faults 

Once the possible fault locations have been narrowed down to a single candidate, heuristic algo- 
rithms to guess a replacement for the faulty instruction are applied. From the values of the environ- 
ment before and after the faulty statement, and from the statements internal structure, instructions 
are synthesized to replace the incorrect statement [ SW99|. This process can be aided by complemen- 
tary models (Section K^l . to restrict the search space for candidate instructions. We briefly sketch the 
synthesis algorithm; see |SW99I for further details. 

Let s be the statement to be replaced. The set of replacement statements for s is derived according 
to the type of s and is constrained by a parameter k that limits the maximum size of the replacement. 
Replacements that do not satisfy the static type declarations in the original program are not consid- 
ered, as we are only interested in corrections that satisfy the basic requirements of the language and 
the compiler. Possible replacements for constants and variables are constants, different variables, or 
calls to methods defined in the program. Method calls can be replaced either by a call to a different 
method (using a subset of the original calls arguments, or synthesizing new arguments), or by one of 
it's arguments (if any). For each replacement, a penalty measure ("size") is assigned, which measures 
the deviation from the original program, with zero being no modification. 

The algorithm finds suitable replacements by enumerating possible replacements up to size k, 
ignoring all candidates that are inconsistent with the types and values derived for the diagnosis can- 
didate ab(s). Thus replacements more similar to the original program are tested earlier and are pre- 
ferred to less similar statements. This algorithm can be extended to incorporate information provided 
by complementary models, as is demonstrated in the example in Section[5| In this case, variables that 
are indicated by the complementary model are assigned lower penalty values than other variables, 
resulting in former candidates being preferred. 

For example, statement float circ = 2.f*r*3.1 41 f has the following replacement candidates: replac- 
ing either constant with another constant (size 1) or with a variable (size 2), or with a method call 
without arguments (size 2). r can be replaced by a constant, another variable, or a method call with- 
out arguments (size 1, 1, and 2, respectively). Operators can be replaced with any of their arguments, 
a different operator, or a method call taking two arguments. Finally, the variable on the left hand side 
of the assignment can be replaced with any other assignable variable of the same type. 

The modification of the model to incorporate the replacement instructions is done by introduc- 
ing specialized mode assumptions syn(\l\,r) and _| sj/n([7]), where I is the program point where the 
replacement r is applied. -^syn(\l\) expressed that no modification takes place at I. 

4.4 Complementary Models 

Past experiences with MBD have shown that MBD provides excellent results when diagnosing func- 
tional faults. However, for structural faults, the semantics-based models do not provide sufficient 
information to accurately detect such faults. Furthermore, unless the test case specification is unrea- 
sonably detailed, for many programs a large number of diagnoses remains. 

To overcome these problems, | StuOl | proposed to utilize complementary models, in particular 
representations of design information, to obtain the necessary information to guide the diagnostic 
engine. An advantage of this approach is that it integrates nicely into our framework without placing 
additional burden on the user. 

For example, consider the state diagram in Figure|3] The automaton can be interpreted as a spec- 
ification expressing that for each object the first call to method getValue (if any) must be preceded by 
a call to setValue. Translated into assertion statements and incorporated into our debugging engine, 
this model can be used to detect wrong or missing method calls, as demonstrated in the next section. 
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1 class Item { 

2 int value; 

3 void setValue(int v) { value = v; } 

4 int getValue() { return value; } 
s } 

6 class Main { 

7 ltem[] items; 

8 int first, last; 

9 /** @pre: (n > 0) 7 

10 void setup(int n, int d) { 

11 int i = 0; 

12 int k = 1 ; 

13 items = new ltem[n]; 

14 while (i < items. length) { 

15 Item item = new ltem(); 

16 items[i] = item; 

17 k*=d; 

18 i++; 

19 } 

20 first = items[0].getValue(); 

21 last = items[n-1].getValue(); 

22 } 

23 /** @post: (first == d) && 

24 * (last == Math.pow(d,n)) && 

25 * (items. length == n) 7 

26 } 



Figure 1 : Example Program 

Specifically, we propose to use partial specifications, i.e. pre- and postconditions and assertions, 
to generate additional conflicts. This provides multiple advantages: 

• Paths of the model can be eliminated and possibly new conflicts be generated by checking the 
assertions. 

• Assertions can be valid for multiple test cases, which avoids specifying program behavior sep- 
arately for every test case and values. 

• By comparing the dependencies between variables in pre- and postconditions, structural faults, 
such as wrong assignments or missing statements, can be detected iStuOll . A similar approach, 
but without exploiting test case information, was used in |Jac95| . 

5 Example 

This section puts together all the previous sections and demonstrates the framework's ability to lo- 
cate and correct faults. 

In this example, the interval abstraction from |CC77| is used to approximate a set of integer val- 
ues. The model is structured such that diagnosis components represent single statements. For sim- 
plicity, hierarchic modeling is not applied, as the method's structure is rather simple. Also, the ex- 
ample does not require termination heuristics for loops or method calls. For objects created on the 
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getValue 
setValue 



Figure 2: Valid Call Sequences for Item 

heap, a simple abstraction aggregating all objects created at a specific location into one abstract model 
variable, corresponding to the allocation site, is used ICor98l . 

Consider the program in Figure^ where the statement item.setValue(k) is missing after line 17. 
Further, assume a test case T = {[[J h-> {n = 3,d = 2), [22] i-> (items[k\. value = 2 k+1 (k e [0..2]))} 4 
and the contract specification given in the method comments. Note that the test case specification 
expresses the intended result of the program. Also, we are given a complementary model that specifies 
that for each instance of class Item, the method setValue() must be called before get Value() is invoked 
(see Figure|5). This is translated into a separate instance variable ltem._callstate, which is initialized 
to 1, denoting the state before the first method call in Figure|2 At the entry point of method set Value() 
_callstate=2 is inserted, indicating that after the method is called, the automaton in Figure |2 is in 
state 2. Similarly, in method getValue(), the assertion always _callstate==2 is inserted. 5 

When the method setup() is analyzed using the test case, the conflict C = {-iq&([l3l), — iq&([T5l), 
-iqbfflol)} is derived: [121, [TT], and \3\ do not influence the result or the call sequence at all and can 
therefore be removed; when [3], [HI , [HI, [l6l and [18] are abnormal, the complementary model in Fig- 
ure[2]still derives a conflict with [20], as setValue() is not called before get Value(); [21] can be removed 
for the same reason. 

The diagnostic process continues with the assumption that at least one component in C is faulty. 
Rerunning the model for each component, the following conflicts are derived: a6([l3]) conflicts with 
{-.ao([4l),^afr([Tll),-.afr([T^ new Item[n1 with an- 

other expression still causes a contradiction for first in line 20, or a NullPointerException. For ao([l5"1), 
no type compatible replacement for new ltem() exists and, therefore, this assumption is not con- 
sistent either. a6([20[) induces the conflict {^a6([l^) / ^a6([T5l),-iab([l6l),-ia6([2T1)} ) as [21] either causes a 
NullPointerException, or the the complementary model again derives a call sequence conflict. 

As none of the attempts to restore consistency by assuming abnormality for any of the compo- 
nents of the initial conflict is successful, no single-fault diagnosis exists for the given program and 
test case. As a consequence, the diagnostic process has to choose between increasing the diagnosis 
cardinality or to search for structural faults. As we are interested in simple faults, it is reasonable to 
look for structural faults before increasing diagnosis cardinality. 

Using the model from Figure |21 and from the conflicts above, it can be deduced that a call to 
setValue() is missing. From the conflict C and the knowledge that the objects causing a contradiction 
were created in [15], the missing call can be inserted between [15] and [20] (denoted 1 15' I — |l9'D . 

The diagnostic process is restarted, using four new rules to insert a synthesized statement s' (Sec- 
tion 14. 3t at location I whenever syn (E],s') is assumed (with -isynflT]) being the default). The simplest 
candidates including a call to setValue() are of the form a.setValue(/3), where a e{item,items[a']}, 
a', (3 e{first,last,i,k,n, d). 

To further restrict the synthesis candidates, we utilize dependency information provided by a 
complementary model: The postconditions of the method imply a dependency from variable d to 
the variables first and last. On the other hand, these dependencies cannot be derived from the imple- 
mentation. As first and last depend on items[]. value only, either first and last directly, or items[]. value 
must also depend on d. Therefore, the synthesized statements using d or k as argument to setValue() 

4 Components corresponding to statements are identified by the statement's line number. 

°Note that the mapping from sequence diagrams to assertions is more complicated if a state diagram contains multiple paths 
leading to a method. For simplicity, we refrain from a detailed discussion in this paper. 
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are preferred. This example also illustrates that it can be advantageous to express assertions about 
programs in terms of variables of the program instead of test case specific values, where comparing 
dependencies is not possible. 

With models that have been modified by adding the synthesized expressions, three diagnoses 
are obtained: syn (\l5'\ , itemsfi'l.setValue(k)) and syn(Jl\, item.setValue(k)) with I e {17', 18'}. Other 
candidates are not consistent for the following reasons: 
Location Candidate Conflict 

|15'| — 118 7 ] item.setValue(d) Contradiction with test case (for first or last) 

[T5 7 ], [Wl item.setValue(k) Contradiction with test case (for first or last) 

QZLQZ] item.setValue(k) — 

fl&n items[a!].setValue(/3) Uncaught NullPointerException 

IWl — \W} items[7].setValue(/3) Contradiction with test case (for first or last) 
[Wl — \W} items[k].setValue(/3) Uncaught ArraylndexOutOfBoundsException 
[l8 7 1, \T¥\ items[i].setValue(/3) Uncaught ArraylndexOutOfBoundsException 
rWI items[i].setValue(/3) Contradiction with test case (for first or last) 

\rf\ items[i].setValue(d) Contradiction with test case (for first or last) 

[TF1 items[i].setValue(k) — 

(a e {d,k,n,first,last},/3 e {d,k},7 e {d,n,first,last}) 
Note that the combination of dynamic execution and static analysis is more powerful than static 
analysis alone. As a demonstration, consider the synthesized statement items[d].setValue(d). Our 
model is able to derive a conflict with variable first, whereas static analysis cannot because elements 
of the array are approximated as [0..d] (assuming an interval abstraction |CC77| for Item. value, and 
a heap abstraction that does not distinguish between items[0] and items[d]). 

Finally, the suggestion to insert either items[i].setValue(k) after line 17, or item.setValue(k) after 
lines 17 or 18 is presented to the user. 



6 Sparse Trace Representation 

This section describes a generalized notion of program trace and a sparse representation thereof. This 
representation makes it possible to avoid copying parts of the dynamic data structures created by a 
program, as was required by previous models |MayOO|. 



Definition 4 (Variable Identifier) A variable identifier is either the canonical name of a local or static vari- 
able, or is composed of an object identifier o and a canonical name of an instance variable v (denoted o.v). 

The canonical name of a variable is formed by prefixing its name with the fully qualified name of 
the scope the variable is defined in. For example, the canonical name of static variable out defined in 
class System, which is defined in package java.lang, is java.lang. System. out. Object identifiers are an 
abstraction of memory addresses for objects created on the heap. In this work, we use the statement 
that created the object as identifier. For multi-dimensional arrays, the index of the parent array is 
included to distinguish different sub-arrays. 

Definition 5 (Environment) An environment e is a tuple (c : I, V), where c G C is a unique context iden- 
tifier and I G C the label of the statement e is associated with. V is a mapping from variable identifiers into 
abstract values. £ denotes the set of all abstract environments V. 

In this work, context and partition are used in the sense of points-to analysis or call graph con- 
struction | GDDC97 [ and represent an abstraction of the call site of a method. Context identifiers are 
used to distinguish different instances of a program part during analysis. For example, if a method 
is called multiple times in a trace, the analysis of the two calls can be merged into a single analy- 
sis, using the merged input and output environments of both calls. While speeding up the analysis, 
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merging, i.e. partitioning, contexts results in diminished accuracy and is applied only when neces- 
sary. Traces without loops can be analyzed without merging, while recursive calls or loop statements 
may require approximation in case the recursion depth or the number of iterations cannot be deter- 
mined. 

The relationship between concrete and abstract values is given by the abstraction function se- 
lected for the abstract interpretation. An abstract environment associates each variable identifier 
with an abstract value, thus approximating the set of concrete values in a non-relational way. For 
example, the well-known interval abstraction |CC77| approximates a set of integer values with an 
interval spanning all the values in the set. 

Every program is transformed into a simple intermediate representation, consisting of assign- 
ments, primitive operations and method calls at top-level. 

Definition 6 (Program) A program P is a pair (S, 1Z), where S is a finite set of statements I : s, each labeled 
with a unique label I e C.1ZQ T(£ ) x T(£) is a transfer relation, specifying the possible transitions between 

concrete environments. T{£) = {7(e) |e e £}. 

For short, (a, b) 6 1Z is denoted a — » b. 

A context selection function C generates a label for the destination environment, given an envi- 
ronment. 

Definition 7 (Execution Trace) The execution trace T ofP is defined as T = IJi>o ^"*/ w ^ = {^p7(eo) 

p], T l+1 = T* U {p -> q\3 r r^y p,j(p) 3 7 (s), s = (c : l,V),d = C(s),q= {c 1 : l,map(T\c' : !)UV)}. 
eo denotes the abstract environment at the starting point of the trace. map{T % ,c' : I) denotes the variable 
mapping for the environment labeled c' : I in T l (L if none exists), and U is the join operator of the abstract 
domain lattice. 

This definition builds the graph containing all feasible paths, starting from eo. Given the reachable 
environments from the previous iteration, new transitions are added leading to the reachable envi- 
ronments as specified by 72.. 

The context selection function C : £ ^> C determines the context of the target environment, given 
the source environment. For recursive method calls and loops, infinite execution sequences have to 
be finitely approximated by partitioning the set of all execution contexts into finitely many partitions. 
C can be influenced by the user or by heuristics to adjust the degree of imprecision. As mentioned 
in Section l42l a bounded approximation of the call stack and loop counter can be used to analyze 
recursive and iterative program constructs. For other program elements, C = Id is sufficient, as no 
approximation is necessary. 

Building on the (Static Single Information form (SSI) |Ana99 MS02|, a separate copy of all used 
variables is created for each branch in the execution trace. The SSI form makes use of <f> and a func- 
tions, which deal with data flow information spanning control flow paths. 4> functions are placed 
at control flow join points and combine the values from the incoming branches into an approximate 
value that is used for references to that variable below the 4> function. Similarly, a functions are placed 
at control flow branches and create separate copies of the incoming value for each branch. Instead of 
computing locations for a and <fi functions statically, we utilize test case information to restrict exe- 
cution paths. This makes it possible to omit many of the a and <j> functions, which in turn produces 
simpler models. 

6.1 Incremental Trace Construction 

To allow for efficient computation of the used and modified variables, the trace representation is 
split into two parts. One part is a static approximation of all possible traces, used to determine basic 
blocks where <fi and a functions may be necessary. The other part represents the feasible execution 
paths through the program, starting from e . 
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By constructing the trace incrementally while executing a test case, the used and modified vari- 
ables, and in particular, the used and modified objects, are known. As a consequence, only the objects 
that are actually modified by a statement need to be updated, leaving all other objects unmodified. 
Consequently, subsequent statements are connected directly to the last modification of their used ob- 
jects, instead of being connected to the last modification of any instance of the same type. Therefore, 
copying values of unmodified instances is unnecessary and can be omitted. 

The static approximation Ts of C o 1Z for each method is derived from a control flow graph (CFG) 
as described in |MS02[. This is possible as Section I4TTI restricts C such that only for method entry 
nodes or loop headers, C ^ Id is possible. From the approximation, the DF graph | Sre95 1 is con- 
structed. The DF graph contains all nodes of the trace's CFG, indicating nodes which are locations 
of possible <j> functions. From each node n in the graph, links point to the 4> functions in the domi- 
nance frontier of n. 6 Therefore, by reversing the direction of the links, each <f> function is linked to the 
collection of nodes which give rise to <f>. Each node is labeled with an unique identifier. 

The representation Td of all feasible execution paths is built by repeatedly applying Definition|7| 
starting from the entry environment eo. Transitions are grouped into basic blocks, with linear transi- 
tion sequences 7 being compressed into one block. 

Environments with multiple outgoing transitions in Td denote the end of the current basic block. 
For each outgoing transition p — > q with q £ Td, new basic blocks are created. Otherwise, q already 
exists and just gains a new incoming link. At this point, several steps are necessary to preserve the 
correctness of Td : 

First, in case q is not the first environment of a block B, B is split into two parts, Bo and B\, 
consisting of the transitions leading to q and the remaining path starting at q, respectively. B\ is 
inserted as a successor of Bq and the link p — > q is added. 

Next, the set B = DF~ 1 (q) of blocks giving rise to a <f> function at this environment q is determined 
using the links in Ts, where only blocks are considered that are actually instantiated in Td for the 
current context. For each b 6 B, the set of modified variables is determined and <fr functions are 
created for each variable (unless they already exist). 

To maintain correctness of Td, the ordering in which the transitions are processed is crucial. It 
must be ensured that all modified variables for a block are known before the block is used to generate 
other (j> functions. This can be ensured by suspending the processing of 4> function generation, in case 
not all blocks of the current context corresponding to blocks in B have been analyzed completely, or 
are known to be unreachable. In addition, an ordering has to be imposed on contexts and labels, 
such that loops and called methods are analyzed completely before any of the successor transitions 
are expanded. If assuming the proposed context selection strategy from Section f4.1l this is not a 
severe restriction for our framework. 

If the graph is cyclic, this ordering is not enough, and a fixpoint algorithm needs to be used 
(details are omitted for brevity). 

The introduction of a functions |Ana99[ for used variables is handled similarly to functions. 
Possible locations for a functions are computed using Ts with the direction of all arcs reversed, 
and an auxiliary environment that postdominates 8 all exit environments in the original Ts- Special 
treatment of cyclic structures is not necessary in this case. 

Whenever a branch of the trace is found inconsistent, the branch is removed and replaced with 
a summary of the part of the derivation of the inconsistency that is local to the branch. In case the 
branch is the only outgoing or incoming connection to a a or <fi function, the function is removed and 
all used associated variable are redirected to the previous definition. Although branch elimination 
is not necessary for the initial forward trace construction (as only consistent branches are followed), 
existing inconsistent branches may be found in subsequent backward and forward iterations. 



6 The dominance frontier of a node n contains all nodes n' of which n dominates an immediate predecessor of n' , but not n' 
itself. It can be shown that these are exactly the locations where <f> functions need to be placed. 

7 A linear transition sequence is a nonempty sequence {e; — » ej+i —»•••—» ei+k), where none of the e;+i, . . . , ej_|_fc_i has 
more than one predecessor or successor. 

8 An environment ei postdominates ei iff all paths from to the exit environment visit e\. 
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6.2 Complexity 

The time complexity of the trace construction is 0(njj ■ max(ns,n£>) 2 ■ a(rio)) in the worst case, 
where rig and rijj denote the number of blocks in T$ and the number of environments in Tq, respec- 
tively. a(nj}) represents the worst case complexity of the fixpoint computation, which depends on 
the program structure and on the abstract domain lattice. 

7 Related Work 

Automated debugging has been an active area of research for several decades, resulting in a large 
number of different methodologies using various assumptions and algorithms. 

In Program Slicing |Wei84 Tip95|, statements that cannot influence the value of a variable at a 
given program point are eliminated by considering the dependencies between the statements. Back- 
ward reasoning from output values, as in our approach, is not possible. Similar ideas were success- 
fully utilized in a MBD tool analyzing VHDL programs IFSW99I IWo"tul1 . 

| BH93 BH95 1 use probability measurements to guide diagnosis. The program debugging process 
is divided into two steps. In the first one, program parts that may cause a discrepancy are computed 
by tracing the incorrect output back to the inputs and collecting the involved statements. In a second 
step, a belief network is used to identify the most probable statements causing the fault. Although 
this approach was successful in debugging a very large program, it requires statistics relating the 
statement types and fault symptoms, which makes it unsuitable for debugging general programs. 

The idea of path information to guide debugging was also applied by other researchers, such 
as program dicing |Tip95[ and similar heuristics |PS92| and visualization of test results |JHS02| . 
Whereas those ideas seem to provide good results, they are even more valuable when integrated 
into a model-based debugging environment, as they can provide the necessary information to dis- 
criminate between diagnoses and aid the selection of more likely candidates | MSWW02b | . 

Jackson |Jac95 1 introduces a framework to detect faults in programs that manifest through changed 
dependencies between the input and the output variables of a program. The approach detects differ- 
ences between the dependencies computed for a program and the dependencies specified by the user. 
It is able to detect certain kinds of structural faults but no test case information is exploited. Whereas 
Jackson focuses on bug detection, the model-based approach is also capable of locating faults. Fur- 
ther, the information obtained from present and absent dependencies can aid the debugger to focus 
on certain regions and types of faults, and thus find possible causes more quickly. 

IHun9 8 1 applies the idea of MBD to the domain of object-oriented languages by building models 
for programs written in Smalltalk. The model used in his work is based on dependencies between 
instance variables and method calls that modify them. The observations state whether the computed 
value of a variable is correct or not, regardless of its concrete value. This approach is limited to 
programs that contain a single faulty statement. Also, previous results showed |Wie01| that while 
dependencies are a valuable tool to isolate faulty modules, more expressive models are needed to 
locate faults on a finer-grained level and to reduce frequent user-interaction. 

IHZO O | introduces an algorithm that compares a faulty program to a close correct variant to de- 
termine changes that cause the misbehavior. Although the algorithm seems to be highly effective for 
test case minimization and has also been applied to locate failure causes in programs |CZ00|, the ap- 
proach generally requires a close and correct variant of the program (or a preselection of "interesting" 
statements, for example in form of grouped changes from a versioning system) to be effective. 

ICFD 93 1 were the first to study model-based debugging, with logic programs as language of 
interest. Their approach was later extended and refined by | Bon94 BP94 1 . Their approach connects 
diagnosis and debugging by identifying horn clauses to be added or removed from programs to 
fix a fault. They show that the MBD approach is more efficient in terms of user interaction than 
Algorithmic Debugging !S ha83l . 

| FFJSOO | apply similar ideas to knowledge base maintenance, exploiting hierarchical information 
to speed up the diagnostic process and to reduce the number of diagnoses. 
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Following |CFD93|, MBD was extended to imperative and concurrent languages, in particular 
to a subset of VHDL IFSW99I . This work showed that MBD can be successfully applied in this do- 
main to isolate faulty processes. Diagnosing programs at a finer level of granularity is still ongoing 
research IP W 031 and requires overcoming difficulties related to temporal and concurrency-related 
aspects of the VHDL language. 

Mateis et al. |MSW00| introduce a dependency-based model for Java programs that abstracts 
from concrete variable values. However, for programs with complex structure, either a high amount 
of user-provided information is necessary, or the results are relatively coarse. In |May00| it was 
extended to simulate program execution. The models are limited to structured, non-recursive pro- 
grams and are not as expressive as the abstract-interpretation-based approach when the behavior of 
complex components is only partially deducible given a test case and diagnostic assumptions. 

Previous research in MBD has resulted in a set of tools that successfully demonstrated the poten- 
tial of the approach. The main strength of the model-based techniques is that reasoning strategies are 
separated from conflict detection, which makes it feasible to plug-in a variety of program analysis 
and debugging methods, provided the results of the analysis can be mapped back to the program's 
source code. A number of models have been developed and analyzed, resulting in promising re- 
sults, mainly in the domain of functional faults (such as wrong constants, operators, conditional 
expressions, etc.). However, the combination of multiple models and reasoning strategies to improve 
accuracy and reduce user interaction is still ongoing research and needs further evaluation, in par- 
ticular with a larger set of realistic programs. This work aims at making a first step in this direction 
by combining abstract-interpretation-based models with complementary models to correct omitted 
statements and structural faults. Also, the implementation of most of the models currently is only in- 
complete and experimental. In particular, no optimizations for speed have been done, which makes 
the comparison with other approaches rather difficult. 

Abstract Interpretation to analyze programs was first introduced by ICC77I . and later extended 
by |Bou93 CC00| to include assertions for abstract debugging. Their approach aims at analyzing 
every possible execution of a program, which makes is suitable to detect errors even in the case 
where no test cases are available. A common problem of these approaches is that of choosing ap- 
propriate abstractions in order to obtain useful results, which hinders the automatic applicability of 
these approaches for many programs. IBou92l introduces a relaxed form of representation for ab- 
stract interpretation, which allows for more complex domains, while building the structure of the 
approximation dynamically. Our framework is strongly inspired by this work, but provides more 
insight on how to choose approximation operators for debugging, in particular in the case where test 
information is known. These questions are not addressed in !B ou92l . 

Recently, model checking approaches have been extended to attempt fault localization in coun- 
terexample traces. | BNR03 1 extended a model checking algorithm that is able to pinpoint transitions 
in traces responsible for a faulty behavior. IGV03I presents another approach, which explores the 
neighborhood of counterexamples to determine causes of faulty behavior. These techniques mostly 
consider deviations in control flow and do not take data dependencies into account. Also, the deriva- 
tion of the abstract model from the concrete program usually is non-trivial and is difficult to auto- 
mate. 

8 Conclusion 

We have presented an automatic debugging approach utilizing model-based diagnosis together with 
an abstract interpretation based conflict detection framework. Based on experiences with previous 
models |MSWW02a|, this framework is able to detect large classes of programming errors, such as 
faulty expressions and faults in control flow, given a set of test cases and partial specifications of the 
programs behavior. This work extends the approach to provide more accurate results in cases where 
previous models could not derive conflicts by approximating loops and recursive function calls using 
abstract interpretation. Further, the introduction of complementary models allows to extend this ap- 
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proach to structural faults. The abstract interpretation framework makes it possible to parameterize 
the framework in various directions: the approximation of variable values can be chosen, heuristics 
for partitioning of context for static analysis and heap analysis are parameterizable, and heuristics 
for detection of nontermination are incorporated to avoid nonterminating diagnoses. The frame- 
work's ability to locate and correct certain faults automatically was demonstrated using a simple 
example program. Possible extensions are the representation for abstract domains from [ Bou92l , and 
the analysis and refinement of heuristics for context partitioning and termination detection. While 
those heuristic s are not essential for our approach, abstractions tailored to specific programs and 
specifications ICDH+OOI can improve the results dramatically. 
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